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Abstract 


This document specifies URL (Uniform Resource Locator) schemes "tel", 
"fax" and "modem" for specifying the location of a terminal in the 
phone network and the connection types (modes of operation) that can 
be used to connect to that entity. This specification covers voice 
calls (normal phone calls, answering machines and voice messaging 
systems), facsimile (telefax) calls and data calls, both for POTS and 
digital/mobile subscribers. 


Table of Contents 


<3 REGUETFEMENWS® gos Tecna e anune wee Web Biel Sed woe Stee Aa ead See eee Bee le S 
URL schemes for telephone calls ........ cee eee eee ee ee ee eee 
Applicabrlity -mediaa Oise esene sgl dk a! ob cole Monde ode gS Goda gael Seared weg 
We (URE SCHEMES seta a a A she. aval ea dhs ie veneers: oie oa ase eee: os aie 
"hax! URL “SCHEME y nianna Goce Sot Se a OS Siete oe, Se Slee toe A ES 
rmodem". UREN SCHEMES co Asi tataa ts cea sive or Slee = car el fore ohterier-e neh eye Series 4ener A Ses 
Parsing telephone, fax and modem URLS ...............2-22206- 
el ACA? Ge bape leech ed cree a e eee ie, a aa a area Mele ge a a emcee: Gos. artes Teh hal 
Phone numbers and their Scope ...... eee ee ee eee ee ee eee 
Separators in phone numbers coe ss ek we ee ee eee ee ie 
Converting the number to the local numbering scheme ...... 
Sending post-dial sequence after call setup .............. 
Pauses in dialing and post-dial sequence ................. 
ESDN’ suüubaddresses Bk ster Geers ea aaea exe Weds a Bide ee ecw ee! os 


NNNNNNNNNNNNNKFHREH BE 
aAanaanann»nannswne 
ee 
PRPRODOOYNNYNADADHBWWWWDND 


YAO BWD 


Vaha-Sipila Standards Track [Page 1] 


RFC 2806 URLs for Telephone Calls April 20 


Or B33) SUbAGDIEESSeS@ tes dco ete es ee eee ee ne eee ee 9 tee See ae eee 
<9 Data Cal], parameters sn wide ond eke E plane ene aa Ma Segue LE ENS Sere a Me ered S 
.10 Telephony service provider identification ............... 
sah Additonal: paramecers: neaga sh ise dcdea Beveled cutee Gave ite & G8 
Examples Or ISS concise toa: tei ene ce lane alice ghese one E at etch seipan a E A tertel af wnat seven ey ees 
Rationale behind the syntax 2... cee eee ee eee ee ee eee 
1 Why distinguish between call types? ................--2.2. 
2 Why eee TS MSO kia eiaa eee le teh See Se fo eae Ok a Aid sie, he i 
.3 Why to use E.164-style numbering? © oc cee dss 8 osen's wes eo en 
4 Not everyone has the same equipment as you ............... 
-5 Do not confuse numbers with how they are dialled ......... 
Comments (OT USAGES? jase sists Se dss tess Sire che Shia Be Satan et acess hey Sh E Se Tons: sra aT e a 
References legarra naaa e one lays e ae a e E a cone niso a a a Gers 
Security ConsidératIions seese t ooe ea pa a e eR eee oS ae E S 
Acknowledgements C reret asee a e Cs r E E E aed BS RE 
AUENOP SS: Address s recer iere se aE see Sse R e Siete a e RS P i a 


NNN NNN ODAU 


DIDNT BPWNHNNNNNNNNDN NH 


1. Introduction 
1.1 New URL schemes 


This specification defines three new URL schemes: "tel", "fax" and 
"modem". They are intended for describing a terminal that can be 
contacted using the telephone network. The description includes the 
subscriber (telephone) number of the terminal and the necessary 
parameters to be able to successfully connect to that terminal. 


The "tel" scheme describes a connection to a terminal that handles 
normal voice telephone calls, a voice mailbox or another voice 
messaging system or a service that can be operated using DTMF tones 


The "fax" scheme describes a connection to a terminal that can handle 


telefaxes (facsimiles). The name (scheme specifier) for the URL is 
"fax" as recommended by [E.123]. 


The "modem" scheme describes a connection to a terminal that can 

handle incoming data calls. The term "modem" refers to a device tha 
does digital-to-analog and analog-to-digital conversions; in additi 
to these, a "modem" scheme can describe a fully digital connection. 


The notation for phone numbers is the same which is specified in 
[RFC2303] and [RFC2304]. However, the syntax definition is a bit 
different due to the fact that this document specifies URLs whereas 
[RFC2303] and [RFC2304] specify electronic mail addresses. For 
example, "/" (used in URLS to separate parts in a hierarchical URL 
[RFC2396]) has been replaced by ";". In addition, this URL scheme h 
been synchronized with [RFC2543]. 
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When these URLs are used, the number of parameters should be kept to 
the minimum, unless this would make the context of use unclear. 
Having a short URL is especially important if the URL is intended to 
be shown to the end user, printed, or otherwise distributed so that 
it is visible. 


1.2 Formal definitions 


The ABNF (augmented Backus-Naur form) notation used in formal 
definitions follows [RFC2234]. This specification uses elements from 
the ’core’ definitions (Appendix A of [RFC2234]). Some elements have 
been defined in previous RFCs. If this is the case, the RFC in 
question has been referenced in comments. 


Note on non-unreserved characters [RFC2396] in URLs: the ABNF in this 
document specifies strings of raw, unescaped characters. If those 
characters are present in a URL, and are not unreserved [RFC2396], 
they MUST be escaped as explained in [RFC2396] prior to using the 
URL. In addition, when parsing a URL, it must be noted that some 
characters may have been escaped. 


An example: ABNF notation "%x20" means a single octet with a 
hexadecimal value of "20" (in US-ASCII, a space character). This must 
be escaped in a URL, and it becomes "%20". 


In addition, the ABNF in this document only uses lower case. The URLS 
are case-insensitive (except for the <future-extension> parameter, 
whose case-sensitivity is application-specific). 


1.3 Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
Compliant software MUST follow this specification. 

2. URL schemes for telephone calls 

2.1 Applicability 
In this document, "local entity" means software and hardware that can 
detect and parse one or more of these URLs and possibly place a call 
to a remote entity, or otherwise utilize the contents of the URL. 
These URL schemes are used to direct the local entity to place a call 


using the telephone network, or as a method to transfer or store a 
phone number plus other relevant data. The network in question may be 
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a landline or mobile phone network, or a combination of these. If the 
phone network differentiates between (for example) voice and data 
calls, or if the local entity has several different 
telecommunications equipment at its disposal, it is possible to 
specify which kind of call (voice/fax/data) is requested. The URL can 
also contain information about the capabilities of the remote entity, 
so that the connection can be established successfully. 


The "tel", "fax" and "modem" URL schemes defined here do not use the 
hierarchical URL syntax; there are no applicable relative URL forms. 
The URLs are always case-insensitive, except for the <future- 
extension> parameter (see below), whose case-sensitivity is 
application specific. Characters in the URL MUST be escaped when 
needed as explained in [RFC2396]. 


2.2 "tel" URL scheme 


The URL syntax is formally described as follows. For the basis of 
this syntax, see [RFC2303]. 


telephone-url = telephone-scheme ":" 
telephone-subscriber 

telephone-scheme = "tel" 

telephone-subscriber = global-phone-number / local-phone-number 

global-phone-number = "+" base-phone-number [isdn-subaddress] 


[post-dial] *(area-specifier / 
service-provider / future-extension) 


base-phone-number = 1*phonedigit 
local-phone-number = 1*(phonedigit / dtmf-digit / 
pause-character) [isdn-subaddress] 


[post-dial] area-specifier 
* (area-specifier / service-provider / 
future-extension) 


isdn-subaddress = ";isub="_ 1*phonedigit 
post-dial = ";postd="_ 1*(phonedigit / 

dtmf-digit / pause-character) 
area-specifier = ";" phone-context-tag "=" phone-context-ident 
phone-context-tag = "phone-context" 
phone-context-ident = network-prefix / private-prefix 
network-prefix = global-network-prefix / local-network-prefix 
global-network-prefix = "+" 1*phonedigit 


local-network-prefix 1* (phonedigit / dtmf-digit / pause-character) 
private-prefix = (%x21-22 / %x24-27 / %x2C / Sx2F / Sx3A / 
$x3C-40 / %x45-4F / %x51-56 / %x58-60 / 
Sx65-6F / %x71-76 / %x78-7E) 
* ($x21-3A / %x3C-7E) 
; Characters in URLs must follow escaping rules 
; as explained in [RFC2396] 
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service-provider 
provider-tag 
provider-hostname 


future-extension 


token-char 


quoted-string 


phonedigit 
visual-separator 
pause-character 
one-second-pause 
wait-for-dial-tone 
dtmf-digit 
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; See sections 1.2 and 2.5.2 

";" provider-tag "=" provider-hostname 

"tsp" 

domain ; <domain> is defined in [RFC1035] 

; See section 2.5.10 

";" 1*(token-char) ["="  ((1* (token-char) 

["?" 1*(token-char)]) / quoted-string )] 

; See section 2.5.11 and [RFC2543] 

(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 

/ Sx41-5A / %x5E-7A / %x7C / %x7E) 

; Characters in URLs must follow escaping rules 
; as explained in [RFC2396] 

; See sections 1.2 and 2.5.11 

%x22 *( "\" CHAR / (%x20-21 / %x23-7E 

/ %x80-FF )) %x22 

; Characters in URLs must follow escaping rules 
; as explained in [RFC2396] 

; See sections 1.2 and 2.5.11 

DIGIT / visual-separator 


wow / wow / Da a / "yon 
one-second-pause / wait-for-dial-tone 
Mom 

vw" 


wee / "n / "a" / "R" / won / "p" 


The URL starts with <telephone-scheme>, which tells the local entity 
that what follows is a URL that should be parsed as described in this 


document. After that, 


the URL contains the phone number of the remote 


entity. Phone numbers can also contain subaddresses, which are used 
to identify different remote entities under the same phone number. If 
a subaddress is present, it is appended to the phone number after 
";isub=". Phone numbers can also contain a post-dial sequence. This 
is what is often used with voice mailboxes and other services that 
are controlled by dialing numbers from your phone keypad while the 
call is in progress. 
the local entity should send to the phone line. 


The <post-dial> sequence describes what and when 


Phone numbers can be either "global" or "local". Global numbers are 
unambiguous everywhere. Local numbers are usable only within a 
certain area, which is called "context", see section 2.5.2. 


Local numbers always have an <area-specifier>, which specifies the 
context in which the number is usable (the same number may have 
different interpretation in different network areas). The context can 
be indicated with three different prefixes. A <global-network-prefix> 
indicates that the number is valid within a numbering area whose 
global numbers start with <global-network-prefix>. Similarly, 
<local-network-prefix> means that the number is valid within a 
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numbering area whose numbers (or dial strings) start with it. A 
<private-prefix> is a name of a context. The local entity must have 
knowledge of this private context to be able to deduce whether it can 
use the number, see section 2.5.2. Additional information about the 
phone number’s usage can be included by adding the name of the 
telephony services provider in <service-provider>, see section 
2:01.08 


The <future-extension> mechanism makes it possible to add new 
parameters to this URL scheme. See section 2.5.11. 


The <private-prefix>, <token-char> and <quoted-string> nonterminals 
may seem a bit complex at first, but they simply describe the set of 
octets that are legal in those nonterminals. Some octets may have to 
be escaped, see [RFC2396]. 


2.3 "fax" URL scheme 
The URL syntax is formally described as follows (the definition 


reuses nonterminals from the above definition). For the basis of this 
syntax, see [RFC2303] and [RFC2304]. 


fax-url = fax-scheme ":" fax-—subscriber 
fax-scheme = "fax" 

fax-subscriber = fax-global-phone / fax-local-phone 
fax-global-phone = "+" base-phone-number [isdn-subaddress] 


[t33-subaddress] [post-dial] 
* (area-specifier / service-provider / 
future-extension) 
fax-local-phone = 1*(phonedigit / dtmf-digit / 
pause-character) [isdn-subaddress] 
[t33-subaddress] [post-dial] 
area-specifier 
* (area-specifier / service-provider / 
future-extension) 
";tsub="_ 1*phonedigit 


t33-subaddress 
The fax: URL is very similar to the tel: URL. The main difference is 
that in addition to ISDN subaddresses, telefaxes also have an another 
type of subaddress, see section 2.5.8. 
2.4 "modem" URL scheme 
The URL syntax is formally described as follows (the definition 


reuses nonterminals from the above definitions). For the basis of 
this syntax, see [RFC2303]. 
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modem-url = modem-scheme ":" remote-host 

modem-scheme = "modem" 

remote-host = telephone-subscriber * (modem-params 
/ recommended-params) 

modem-—params = "; type=" data-capabilities 

recommended-params = ";rec=" data-capabilities 

data-capabilities = accepted-modem ["?" data-bits parity 
stop-bits] 

accepted-modem = "v2" / "V22" £ "V22b™ / 


"y23" / "y26t" / "y32" / 
"V32b" / "y3ą4" / "yoo" / 
"V110" / "y120" j "B103" / 
"B212" / "x75" / 


"vnd." vendor-name "." modem-type 
data-bits = "7" / wen 
parity = Wy" / "e" / "o" / "m" / "g" 
stop-bits = "]" / mon 
vendor-name = 1* (ALPHA / DIGIT / "-" / "4") 
modem-t ype = 1* (ALPHA / DIGIT / "-" / "+") 


The modem: URL scheme is also very similar to both the tel: and fax: 
schemes, but it adds the description of the capabilities of the 
remote entity. Minimum required compliance is listed in <modem-— 
params> and recommended compliance is listed in <recommended-params>. 
For details, see section 2.5.9. 


2.5 Parsing telephone, fax and modem URLS 
2.5.1 Call type 


The type of call is specified by the scheme specifier. "Tel" means 
that a voice call is opened. "Fax" indicates that the call should be 
a facsimile (telefax) call. "Modem" means that it should be a data 
call. Not all networks differentiate between the types of call; in 
this case, the scheme specifier indicates the telecommunications 
equipment type to use. 


2.5.2 Phone numbers and their scope 


<telephone-subscriber> and <fax-subscriber> indicate the phone number 
to be dialed. The phone number can be written in either international 
or local notation. All phone numbers SHOULD always be written in the 
international form if there is no good reason to use the local form. 


Not all numbers are valid within all numbering areas. The <area- 
specifier> parameter, which is mandatory for local numbers, is used 
to indicate the locale within which this number is valid, or to 
qualify the phone number so that it may be used unambiguously. The 
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<area-specifier> can take three forms: <global-network-prefix>, 
<local-network-prefix> or <private-prefix>. These are used to 
describe the validity area of the phone number either in global 
numbering plan, local numbering plan, or in a private numbering plan, 
respectively. 


If <area-specifier> is present, the local entity MUST NOT attempt to 
call out using the phone number if it cannot originate the call 
within the specified locale. If a <local-phone-number> is used, an 
<area-specifier> MUST be included as well. 


There can be multiple instances of <area-specifier>. In this case, 
the number is valid in all of the given numbering areas. 


The global prefix form is intended to act as the outermost context 
for a phone number, so it will start with a "+", followed by some 
part of an E.164 number. It also specifies the region in which the 
phone number is valid. For example, if <global-network-prefix> is 
"+358", the given number is valid only within Finland (country code 
358) - even if it is a <global-phone-number>. 


The local prefix form is intended to act as an intermediate context 
in those situations where the outermost context for a phone number is 
given by another means. One example of use is where the local entity 
is known to originate calls only within the North American Number 
Plan Area, so an "outermost" phone context can be assumed. The local 
context could, for example, be used to indicate the area code within 
which an associated phone number is situated. Thus "tel:456- 

7890; phone-context=213" would suffice to deliver a call to the 
telephone number "+1-213-456-7890". Note that the version including 
the <phone-context> implies further that the call can only be 
originated within the "area code 213" region. 


The <private-prefix> form is intended for use in those situations 
where the context cannot be expressed with a start of a global phone 
number or a dialing string. The <private-prefix> is actually a name 
of a private context. The creator of the URL and the local entity 
have been configured to recognize this name, and as such they can 
interpret the number and know how they can utilize the number. For 
example, a private network numbering plan may be indicated by the 
name "X-COMPANY-NET", but the private dialling plan from the locales 
of the sender of the telephony URL and the local entity are 
different. The syntax of these tokens will be left for future 
specification. The ABNF above specifies the accepted characters that 
can be a part of <private-prefix>. 
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Unless the sender is absolutely sure that they share the same private 
network access digit string with the local entity, then they MUST NOT 
use a dialling plan number (a local phone number, or one qualified by 
a local context), as the result may be incorrect. Instead, they 
SHOULD use a global number, or if that is not possible, a private 
context as the last resort. If the local entity does not support 
dialling into the private network indicated by that context, then the 
request MUST be rejected. If it does, then it will use the access 
digit string appropriate for its locale. 


Note that the use of <area-specifier> is orthogonal to use of the 
telephony service provider parameter (see 2.5.10); it qualifies the 
phone number, whilst the <service-provider> parameter indicates the 
carrier to be used for the call attempt. 


For example, a large company may have private network 
interconnections between its sites, as well as connections to the 
Global Switched Telephone Network. A phone number may be given in 
"public network" form, but with a <service-provider> indicating that 
the call should be carried over the corporate network. 


Conversely, it would be possible to represent a phone number in 
private network form, with a private context to indicate this, but 
indicate a public telephony service provider. This would request that 
the user agent convert the private network number plan address into a 
form that can be carried using the selected service provider. 


Any telephone number MUST contain at least one <phonedigit> or 
<dtmf-digit>, that is, subscriber numbers consisting only of pause 
characters are not allowed. 


International numbers MUST begin with the "+" character. Local 
numbers MUST NOT contain that character. International numbers MUST 
be written with the country (CC) and national (NSN) numbers as 
specified in [E.123] and [E.164]. International numbers have the 
property of being totally unambiguous everywhere in the world if the 
local entity is properly configured. 


Local numbers MAY be used if the number only works from inside a 
certain geographical area or a network. Note that some numbers may 
work from several networks but not from the whole world - these 
SHOULD be written in international form, with a set of <area- 
specifier> tags and optional <service-provider> parameters. URLS 
containing local phone numbers should only appear in an environment 
where all local entities can get the call successfully set up by 
passing the number to the dialing entity "as is". An example could be 
a company intranet, where all local entities are located under a the 
same private telephone exchange. If local phone numbers are used, 
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the document in which they are present SHOULD contain an indication 
of the context in which they are intended to be used, and an 
appropriate <area-specifier> SHOULD be present in the URL. 


In some regions, it is popular to write phone numbers using 
alphabetic characters which correspond to certain numbers on the 
telephone keypad. Letters in <dtmf-digit> characters do not have 
anything to do with this, nor is this method supported by these URL 
schemes. 


It should also be noted that implementations MUST NOT assume that 
telephone numbers have a maximum, minimum or fixed length, or that 


they would always begin with a certain number. Implementors are 
encouraged to familiarize themselves with the international 
standards. 


2.5.3 Separators in phone numbers 


All <visual-separator> characters MUST be ignored by the local entity 
when using the URL. These characters are present only to aid 
readability: they MUST NOT have any other meaning. Note that although 
[E.123] recommends the use of space (SP) characters as the separators 
in printed telephone numbers, spaces MUST NOT be used in phone 
numbers in URLS as the space character cannot be used in URLs without 
escaping it. 


2.5.4 Converting the number to the local numbering scheme 


After the telephone number has been extracted, it can be converted to 
the local dialing convention. (For example, the "+" character might 
be replaced by the international call prefix, or the international 
and trunk prefixes might be removed to place a local call.) Numbers 
that have been specified using <local-phone> or <fax-—local-phone> 
MUST be used by the local entity "as is", without any conversions, 
unless the local entity decides to utilize the information in an 
optional <service-provider> parameter. 


2.5.5 Sending post-dial sequence after call setup 


The number may contain a <post-dial> sequence, which MUST be dialled 
using Dual Tone Multifrequency (DTMF) in-band signalling or pulse 
dialing after the call setup is complete. If the user agent does not 
support DTMF or pulse dialing after the call has been set up, <post- 
dial> MUST be ignored. In that case, the user SHOULD be notified. 
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2.5.6 Pauses in dialing and post-dial sequence 


A local phone number or a post-dial sequence may contain <pause- 
character> characters which indicate a pause while dialing ("p"), or 
a wait for dial tone ("w"). 


Local entities MAY support this method of dialing, and the final 
interpretation of these characters is left to the local entity. It 
is RECOMMENDED that the length of each pause is about one second. 


If it is not supported, local entities MUST ignore everything in the 

dial string after the first <pause-character> and the user SHOULD be 

notified. The user or the local entity MAY opt not to place a call if 
this feature is not supported and these characters are present in the 
URL. 


Any <dtmf-digit> characters and all dial string characters after the 
first <pause-character> or <dtmf-digit> SHOULD be sent to line using 
DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is 
done using direct network signaling (a digital subscriber loop or a 
mobile phone). If the local infrastructure does not support DTMF 
codes, the local entity MAY opt to use pulse dialing. However, it 
should be noted that certain services which are controlled using DTMF 
tones cannot be controlled with pulse dialing. If pulse dialing is 
used, the user SHOULD be notified. 


2.5.7 ISDN subaddresses 


A phone number MAY also contain an <isdn-subaddress> which indicates 
an ISDN subaddress. The local entity SHOULD support ISDN 
subaddresses. These addresses are sent to the network by using a 
method available to the local entity (typically, ISDN subscribers 
send the address with the call setup signalling). If ISDN 
subaddressing is not supported by the caller, <isdn-subaddress> MUST 
be ignored and the user SHOULD be notified. The user or the local 
entity MAY opt not to place a call if this feature is not supported. 


2.5.8 T.33 subaddresses 


A fax number MAY also contain a <t33-subaddress>, which indicates the 
start of a T.33 subaddress [T.33]. Local entities SHOULD support 
this. Otherwise <t33-subaddress> MUST be ignored and the user SHOULD 
be notified. The user or the local entity MAY opt not to place a call 
if this feature is not supported. 
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2.5.9 Data call parameters 


<modem-params> indicate the minimum compliance required from the 
local entity to be able to connect to the remote entity. The minimum 
compliance is defined as being equal to or a superset of the 
capabilities of the listed modem type. There can be several <modem-— 
param> parameters, in which case compliance to any one of them will 
be accepted. <recommended-params> indicates the recommended 
compliance required from the local entity. This is typically the 
fastest and/or the most reliable modem type supported by the modem 
pool. The local entity can use this information to select the best 
number from a group of modem URLs. There can be several recommended 
modem types, which are equally desirable from the modem pool’s point 
of view. <recommended-params> MAY NOT conflict with <modem-params>. 
If they do, the local entity MUST ignore the <recommended-params>. 


The local entity MUST call out using compatible hardware, or request 
that the network provides such a service. 


For example, if the local entity only has access to a V.22bis modem 
and the URL indicates that the minimum acceptable connection is 
V.32bis, the local entity MUST NOT try to connect to the remote host 
since V.22bis is a subset of V.32bis. However, if the URL lists V.32 
as the minimum acceptable connection, the local entity can use 
V.32bis to create a connection since V.32bis is a superset of V.32. 


This feature is present because modem pools often have separate 
numbers for slow modems and fast modems, or have different numbers 
for analog and ISDN connections, or may use proprietary modems that 
are incompatible with standards. It is somewhat analogous to the 
connection type specifier (typecode) in FTP URLs [RFC1738]: it 
provides the local entity with information that can not be deduced 
from the scheme specifier, but is helpful for successful operation. 


This also means that the number of data and stop bits and parity MUST 
be set according to the information given in the URL, or to default 
values given in this document, if the information is not present. 


The capability tokens are listed below. If capabilities suggest that 
it is impossible to create a connection, the connection MUST NOT be 
created. 


If new modem types are standardized by ITU-T, this list can be 
extended with those capability tokens. Tokens are formed by taking 
the number of the standard and joining together the first letter (for 
example, "V"), number (for example, 22) and the first letter of the 
postfix (for example "bis" would become "b"). 
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Proprietary modem types MUST be specified using the ’vendor naming 
tree’, which takes the form "vwnd.x.y", in which "x" is the name of 
the entity from which the specifications for the modem type can be 
acquired and "y" is the type or model of the modem. Vendor names MUST 
share the same name space with vendor names used in MIME types 
[RFC2048]. Submitting the modem types to ietf-types list for review 
is strongly recommended. 


New capabilities MUST always be documented in an RFC, and they MUST 
refer to this document or a newer version of it. The documentation 
SHOULD also list the existing modem types with which the newly 
defined modem type is compatible with. 


Capability Explanation 
V21 ITU-T V.21 
V22 ETUSTE Wie 22 
V22b ITU-T V.22bis 
V23 ITU-T V.23 
V26t ITU-T V.26ter 
V32 ITU-T V.32 
V32b ITU-T V.32bis 
V34 ITU-T V.34 
v90 ITU-T V.90 
V110 ITU-T V.110 
V120 ITU-T V.120 
X75 ITU-T X.75 
B103 Bell 103 

B212 Bell 212 

Data bits: "8" or "7" The number of data bits. If not 


specified, defaults to "8". 
Parity: "n", "e", "o", Parity. None, even, odd, mark or 


Im). mST space parity, respectively. If 
not specified, defaults to "n" 
Stop: bits: "1" or "2" The number of stop bits. If not 


specified, defaults to "1". 
2.5.10 Telephony service provider identification 


It is possible to indicate the identity of the telephony service 
provider for the given phone number. <service-provider> MAY be used 
by the user-agent to place the call using this network, to enhance 
the user interface, for billing estimates or to otherwise optimize 
its functionality. It MAY also be ignored by the user-agent. 
<service-provider> consists of a fully qualified Internet domain name 
of the telephony service provider, for example 
";tsp=terrifictelecom.com". The syntax of the domain name follows 
Internet domain name rules and is defined in [RFC1035]. 
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2.5.11 Additional parameters 


In addition to T.33 and ISDN subaddresses, modem types and area 
specifiers, future extensions to this URL scheme may add other 
additional parameters (<future-extension> in the BNF) to these URLs. 
These parameters are added to the URL after a semicolon (";"). 
Implementations MUST be prepared to handle additional and/or unknown 
parameters gracefully. Implementations MUST NOT use the URL if it 
contains unknown parameters, as they may be vital for the correct 
interpretation of the URL. Instead, the implementation SHOULD report 
an error. 


For example, <future-extension> can be used to store application- 
specific additional data about the phone number, its intended use, or 
any conversions that have been applied to the number. Whenever a 
<future-extension> is used in an open environment, its syntax and 
usage MUST be properly documented in an RFC. 


<future-extension> nonterminal a rephrased version of, and compatible 
with the <other-param> as defined in [RFC2543] (which actually 
borrows BNF from an earlier version of this specification). 


2.6 Examples of Use 
tel:+358-555-1234567 


This URL points to a phone number in Finland capable of receiving 
voice calls. The hyphens are included to make the number more human- 
readable: country and area codes have been separated from the 
subscriber number. 


fax:+358.555.1234567 


The above URL describes a phone number which can receive fax calls. 
It uses dots instead of hyphens as separators, but they have no 
effect on the functionality. 


modem: +3585551234567; type=v32b?7el;type=v110 


This phone number belongs to an entity which is able to receive data 
calls. The local entity may opt to use either a ITU-T V.32bis modem 

(or a faster one, which is compatible with V.32bis), using settings 

of 7 data bits, even parity and one stop bit, or an ISDN connection 

using ITU-T V.110 protocol. 
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tel:+358-555-1234567; postd=pp22 


The above URL instructs the local entity to place a voice call to 
+358-555-1234567, then wait for an implementation-dependent time (for 
example, two seconds) and emit two DTMF dialing tones "2" on the line 
(for example, to choose a particular extension number, or to invoke a 
particular service). 


tel:0w003585551234567; phone-context=+3585551234 


This URL places a voice call to the given number. The number format 
is intended for local use: the first zero opens an outside line, the 
"w" character waits for a second dial tone, and the number already 
has the international access code appended to it ("00"). This kind of 
phone number MUST NOT be used in an environment where all users of 
this URL might not be able to successfully dial out by using this 
number directly. However, this might be appropriate for pages ina 
company intranet. The <area-specifier> which is present hints that 
the number is usable only in an environment where the local entity’s 
phone number starts with the given string (perhaps singling out a 
company-wide block of telephone numbers). 


tel:+1234567890; phone-context=+1234; vnd.company.option=foo 


The URL describes a phone number which, even if it is written in its 
international form, is only usable within the numbering area where 
phone numbers start with +1234. There is also a proprietary extension 
"vnd.company.option", which has the value "foo". The meaning of this 
extension is application-specific. Note that the order of these 
parameters (phone-context and vnd.company.option) is irrelevant. 


2.7 Rationale behind the syntax 
2.7.1 Why distinguish between call types? 


URLs locate resources, which in this case is some telecommunications 
equipment at a given phone number. However, it is not necessarily 
enough to know the subscriber number in order to successfully 
communicate with that equipment. Digital phone networks distinguish 
between voice, fax and data calls (and possibly other types of calls, 
not discussed in this specification). To be able to successfully 
connect to, say, a fax machine, the caller may have to specify that a 
fax call is being made. Otherwise the call might be routed to the 
voice number of the subscriber. In this sense, the call type is an 
integral part of the ’location’ of the target resource. 
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The reason to have the call type in the scheme specifier is to make 
the URL simple to remember and use. Making it a parameter, much like 
the way modem parameters are handled now, will substantially reduce 
the human readability of this URL. 


2.57.2: Why “gel” as Stell? 
There has been discussion on whether the scheme name "tel" is 


appropriate. To summarize, these are the points made against the 
other proposals. 


callto URL schemes locate a resource and do not specify 
an action to be taken. 

telephone Too long. Also, "tel" considered to be a more 
international form. 

phone Was countered on the basis that "tel" is more 


internationally acceptable. 
2.7.3 Why to use E.164-style numbering? 


E.164 refers to international telephone numbers, and the string of 
digits after the country code is usually a national matter. In any 
case, phone numbers are usually written as a simple string of numbers 
everywhere. Because of this, the syntax in this specification is 
intuitively clear to most people. This is the usual way to write 
phone numbers in business cards, advertisements, telephone books and 
so on. 


It should be noted that phone numbers may have /’hierarchical’ 
characteristics, so that one could build a ’forest’ of phone numbers 
with country codes as roots, area codes as branches and subscriber 
numbers as leaves. However, this is not always the case. Not all 
areas have area codes; some areas may have different area codes 
depending on how one wants to route the call; some numbers must 
always be dialled "as is", without prepending area or country codes 
(notably emergency numbers); and area codes can and do change. 


Usually, if something has a hierarchical structure, the URL syntax 
should reflect that fact. These URLs are an exception. 


Also, when writing the phone number in the form described in this 
specification, the writer does not need to know which part of the 
number is the country code and which part is the area code. If a 
hierarchical URL would be used (with a "/" character separating the 
parts of the phone numbers), the writer of the URL would have to know 
which parts are which. 


Vaha-Sipila Standards Track [Page 16] 


RFC 2806 URLs for Telephone Calls April 2000 


Finally, when phone numbers are written in the international form as 
specified here, they are unambiguous and can always be converted to 
the local dialing convention, given that the user agent has the 
knowledge of the local country and area codes. 


2.7.4 Not everyone has the same equipment as you 
There are several ways for the subscriber to dial a phone number: 


- By pulse dialing. Typically old telephone exchanges. Usually this 
dialing method has only to be used to set up the call; after 
connecting to the remote entity, <post-dial> can be sent to the 
line using DTMF, because it will typically be processed by the 
remote entity, not the telephone network. 


- By DTMF. These are the ’beeps’ that you hear when you dial on 
most phones. 


- By direct network signalling. ISDN subscribers and mobile phone 
users usually have this. There is no dial tone (or if there is, it 
is generated locally by the equipment), and the number of the 
called party is communicated to the telephone network using some 
network signalling method. After setting up the call, <post-dial> 
sequences are usually sent using DTMF codes. 


2.7.5 Do not confuse numbers with how they are dialled 


As an example, +123456789 will be dialled in many countries as 
00123456789, where the leading "00" is a prefix for international 
calls. However, if a URL contains a local phone number 00123456789, 
the user-agent MUST NOT assume that this number is equal to a global 
phone number +123456789. If a user-agent received a telephony URL 
with a local number in it, it MUST make sure that it knows the 
context in which the local phone number is to be processed, or else 
the number MUST NOT be used. Equally, anyone sending a telephony URL 
MUST take into consideration that the recipient may have insufficient 
information about the phone number’s context. 


3. Comments on usage 


These are examples of the recommended usage of this URL in HTML 
documents. 


First of all, the number SHOULD be visible to the end user, if it is 
conceivable that the user might not have a local entity which is able 
to use these URLs. 


Telephone: <a href="tel:+3585551234567">+358-555-1234567</a> 
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Second, on a public HTML page, the telephone number in the URL SHOULD 
always be in the international form, even if the text of the link 
uses some local format. 


Telephone: <a href="tel:+3585551234567">(0555) 1234567</a> 
or even 


For more info, call <a href="tel:+15554383785965">1-555-IETF-RULZ-— 
OK</a>. 


Moreover, if the number is a <local-phone-number>, and the scope of 
the number is not clear from the context in which the URL is 
displayed, a human-readable explanation SHOULD be included. 


For customer service, dial <a href="tel:1234; phone- 
context=+358555">1234</a> (only from Terrific Telecom mobile 
phones). 
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5. Security Considerations 


It should be noted that the local entity SHOULD NOT call out without 
the knowledge of the user because of associated risks, which include 


—- call costs (including long calls, long distance calls, 
international calls and premium rate calls, or calls which do not 
terminate due to <post-dial> sequences that have been left out by 
the local entity) 


- wrong numbers inserted on web pages by malicious users, or sent via 
e-mail, perhaps in direct advertising 


- making the user’s phone line unavailable (off-hook) for a malicious 
purpose 


- opening a data call to a remote host, thus possibly opening a back 
door to the user’s computer 


- revealing the user's (possibly unlisted) phone number to the remote 
host in the caller identification data, and correlating the local 
entity’s phone number with other information such as the e-mail or 
IP address 


—- using the same local number in different contexts, in which the 
number may have a different meaning 


All of these risks MUST be taken into consideration when designing 
the local entity. 
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The local entity SHOULD have some mechanism that the user can use to 
filter out unwanted numbers. The local entity SHOULD NOT use rapid 
redialing of the number if it is busy to avoid the congestion of the 
(signaling) network. Also, the local entity SHOULD detect if the 
number is unavailable or if the call is terminated before the dialing 
string has been completely processed (for example, the call is 
terminated while waiting for user input) and not try to call again, 
unless instructed by the user. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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